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Abstract 

A rigid loop is a for-loop with a counter not accessible to the loop 
body or any other part of a program. Special instructions for rigid loops 
are introduced on top of the syntax of the program algebra PGA. Two 
different semantic projections are provided and proven equivalent. One 
of these is taken to have definitional status on the basis of two criteria: 
'normative semantic adequacy' and 'indicative algorithmic adequacy'. 
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1 Introduction 

In this paper we extend the program algebra PGA |6j with several new instruc- 
tions to deal with so-called rigid loops. Rigid loops are just program fragments 
that impose the repetition of a body a fixed number of times. Rigid loops are 
very limited in expressive power. Indeed finite state PGA-programs with rigid 
loops can be projected into equivalent finite state PGA-programs without rigid 
loops at the cost of a combinatorial explosion in length. Like non-recursive 
procedures, rigid loops may be of use when investigating options for compiler 
writing for specific processor architectures. Our specific motivation to consider 
rigid loops arose when studying the potential gains that may arise from mi- 
crothread multiplexing on a single pipelined instruction processing architecture. 
Following Jesshope et al. in [121 E] loops and nested loops can be usefully split 
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into microthreads which then may be scheduled either in a multiplexed fashion 
on a single pipeline, in an attempt to make use of the unavoidable clock cycles 
in which a single thread on the pipeline features stalling, or concurrently on 
parallel pipelines on a multiple pipeline architecture in order to maximize the 
processing speed for an originally sequential program. Rigid loops have the ad- 
vantage of simplifying dependency analysis, thus shedding more easily light on 
what one might hope to achieve. As it turns out rigid loops are quite interesting 
even without applications like the one just mentioned in mind as a case study for 
projection semantics. Projection semantics has been advocated in [5] as a formal 
modeling technique close to programmers intuitions. Rigid loops can be easily 
provided with a projection semantics at the cost of a combinatorial explosion in 
program length. Here it will be argued that this is not the most appropriate way 
to deal with this issue and another style of projection which avoids this drastic 
blow-up in program length is provided and proven semantically equivalent but 
algorithmically more natural. 

Although 6J provides a clear statement on the objectives and merits of pro- 
jection semantics, it fails to provide a methodology which scales to full size 
program notations by its exclusive focus on semantic issues. Projection seman- 
tics provides the meaning of a program notation, say PGLX, by means of a 
mapping pglx2pga from PGLX to PGA which assigns to each entity in PGLX 
a program object (i.e., an element of a program algebra, in this case PGA). The 
program objects used are finite or infinite instruction streams, over a limited set 
of primitive instructions which goes with the program algebra. As a semantic 
strategy projection semantics is independent of this particular program algebra, 
but we will use PGA because it works and it allows for a very slow build up 
of features, thus permitting a very gradual growth in expressiveness. The key 
dogma of projection semantics is that an entity is a program by either being or 
representing an instruction stream. Instruction streams are program objects, 
i.e., mathematical entities that stand for programs. Thus a projection explains 
how some entity can be considered an instruction stream and only by explaining 
(by way of a projection) what instruction stream an entity represents it can be 
considered a program. It is more precise always to speak of a program represen- 
tation rather than of a program but because that is very uncommon the term 
'program' is used also in cases that a projection does not speak for itself. 

Until a projection has been fixed for an entity it is is a candidate program 
rather than a program. Only by fixing its projection into an instruction stream 
a candidate program becomes a program, comparable to how a document be- 
comes legally binding by the addition of relevant signatures, locations and dates. 
We do not accept the conventional viewpoint that a program can be given a new 
meaning. Rather a candidate program can be made to stand for another pro- 
gram by changing its projection, just as a contract changes when one modifies 
the signatures. Candidate programs may have a quite convincing syntax sug- 
gesting meaning without further ado. We believe that this is never actually 
true. The operational meaning of candidate programs always requires detailed 
description covering a variety of circumstances. Now 'projection semantics' as a 
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style of providing programming language semantics will have to deal with many 
notations that are already in use and that may have the status of candidate 
programs from the perspective of program algebra based projection semantics, 
but for which quite satisfactory semantic descriptions have been foimd by means 
of other techniques. Here we are dealing with providing projection semantics 
for 'known' program notations and the question may arise as to which semantic 
description technique is most effective. 

Claiming definitional status for a projection for a program notation that has 
been given a semantic description already is clearly problematic. Therefore the 
claim can go no further than that a projection might be considered to have 
normative strength scmantically, under the hypothesis that it would be the 
only description at hand, accepting that in many cases it will have not have 
definitional status simply because other definitions have that status already. 
Such a projection, for a known and well specified program notation will be 
called a reconstruction projection semantics in order to acknowledge that a 
definitional status is not claimed. This leads to the position that for Pascal one 
may achieve no more than a reconstruction projection semantics while for Perl 
a projection semantics might still be achievable. 

For new or unknown notations, however, whether useful or not, a projection 
can be claimed to contain primary semantic information which by definition 
cannot be validated or verified against any other description, because of its 
normative nature. Of course validation is possible; by means of a projection 
semantics an operational meaning is assigned to syntactic constructs (assuming 
a string based source language) in a candidate program notation. Because the 
syntax of this candidate program notation is itself a matter of meticulous design 
the operational meaning should make best possible use of the syntax that has 
been made available. If a projection prescribes an unintelligible meaning to 
a construct that might have been given a clear and useful meaning instead a 
design error has occurred which can and probably should be repaired. 

Returning to the issue that known program notations cannot be given a 
projection semantics the following sohition to this somewhat philosophical issTie 
can be found. For projection semantics as a topic of investigation this philo- 
sophical matter is simply solved by always using slightly unconventional syntax 
(however marginal the differences) such that the setting establishes a new syn- 
tax which is given a meaning for the first and therefore definitive time. The 
ability of a projection for a candidate program notation to serve as a carrier of 
intended semantic information is termed normative semantic adequacy. Norma- 
tive semantic adequacy docs not come for free: it requires that comprehensible 
projections into comprehensible programs are used to provide a realistic, sug- 
gestive and useful meaning (in terms of instruction streams) for new syntax. 
Usually a projection will be into a program notation that has been provided 
with a projection semantics already thus giving rise to chains of projections. 

Besides normative semantic adequacy one also expects a projection to rep- 
resent an indication (or model) of how the actual processing of a (candidate) 
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program might in practice proceed. Exponential or even polynomial blow-up of 
the size of an entity during its projecting transformation are signs that indicative 
algorithmic adequacy has not been achieved. 

A projection for a programming notation feature which enjoys both norma- 
tive semantic adequacy and indicative algorithmic adequacy is called a defining 
projection. If it uses some services of type T it will be called a T service based 
defining projection. Using this terminology we will develop in this paper a 
rigid loop counter service based defining projection for PGArl (PGA with rigid 
loops). 

The further content of this paper is divided into four parts: in Section [5] we 
formally introduce threads and services. In Section[3]we introduce the program 
algebra PGA, thread extraction and a further extension of PGA. In Section [J] 
we extend PGA with rigid loops to PGArl, including two forms of projection 
semantics. It is clarified that the projection semantics making use of decreasing 
loop counters enjoys both normative semantic adequacy and indicative algo- 
rithmic adequacy and that the pure projection into PGA fails for the second 
criterion. The paper is ended with some conclusions in Section [S] 

2 Threads and Services 

The behavior of programs under execution is modelled by threads. In this section 
we introduce thread algebra. Then we introduce services, devices that can be 
used by a thread in order to increase expressiveness. 

2.1 Thread algebra 

Basic thread algebra, or BTA for short, is intended for the description of se- 
quential program behavior (see [7]; in [5] BTA is introduced as basic polarized 
process algebra). Based on a finite set A of actions it has the following constants 
and operators: 

• the termination constant S, 

• the deadlock or inaction constant D, 

• for each a £ A, a binary postconditional composition operator _ ^ a > _. 

We use action prefixing a o P as an abbreviation for P < a [> P and take o to 
bind strongest. Furthermore, for G N we define a" o P by a° o P = P and 
a"+ioP = ao(a"oP). 

The operational intuition behind thread algebra is that each action repre- 
sents a request to be processed by the execution environment. At completion 
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of the processing of the request, the environment produces a reply value true 
or false to the thread under execution and may undergo a change of state. The 
thread P <a>Q will then proceed as P if the processing of a yielded the reply 
true indicating successful processing, and it will proceed as Q if the processing 
of a yielded the reply false. 

BTA can be equipped with a partial order and an approximation operator. 

1. C is the partial ordering on BTA generated by the clauses 

(a) for all P G BTA, D □ P, and 

(b) for all Pi, P2, Qi, Q2 e BTA, a & A, 

Pi C Qi & P2 C Q2 ^ A < a > ^"2 C Qi < a ^ Qz- 

2. TT : N X BTA — > BTA is the approximation operator determined by the 
equations 

(a) for all P e BTA, 7r(0, P) = D, 

(b) for all n E N, Tr{n + 1, S) = S, 7r(n + 1, D) = D, and 

(c) for all P,Q e BTA, n e N, 

7r(n + 1, P < a ^ Q) = TT{n, P) < a ^ TT{n, Q). 
We further write 7r„(P) instead of 7r(n, P). 

The operator tt finitely approximates every thread in BTA. That is, for all 
P e BTA, 

3n G N 7ro(P) C ^i(P) C ■ • • C ^„(P) = 7r„+i(P) = ■ • • = P. 

Threads can be finite or infinite. Following the metric theory of |lj as the basis 
of processes in |5j, BTA has a completion BTA°° which comprises also infinite 
threads. Standard properties of the completion technique yield that we may 
take BTA°° as the cpo consisting of all so-called projective sequences. That is, 

BTA°° = {(P„)„eN I Vn e N (P„ e BTA & ^„(P„+i) = P„)} 

with 
and 

(-Pri)neN = (Qn)«eN 44> Vn G N P„ = Qn- 

(For a detailed account of this construction see [3].) 

Let / — {1, ...,71} for some n > 0. A finite linear recursive specification over 
BTA is a set of equations 

X, = tdX) 
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for i G I with X = Xi, Xn and all ti{X) of the form S, D, or X^, <ai>Xi^ for 
S I and G A. In BTA°°, finite linear recursive specifications represent 
continuous operators having as unique fixed points regular threads, i.e., threads 
which can only reach finitely many states. 



Example 1 Let n > 0. The regular thread a" oD is the fixed point for Xi in 
the specification 

{X, = ao X,+i I I = 1, n} U {Xn+i = D}. 
The regular thread a" o S is the fixed point for Xi in 

{Xi = ao Xi+i I i = 1, n} U {X„+i = S}. 

Both these threads are finite. 

The infinite regular thread is the fixed point for Xi in the specification 
{X ^ a o X} and corresponds to the projective sequence {Pn)ni£N with Pq ^ D 
and Pn+i = ao Pn. 

Observe that e.g. a" o D C a" o S, a" o D C a°° but a" o S g a°°. 



For the sake of simplicity, we shall often define regular threads by providing 
only one or more equations. For example, we say that P = a o P defines a 
regular thread with name P (so P = a°° in this case). 

We end this section with the observation that for regular threads P and Q, 
P C Q is decidable. Because one can always take the disjoint union of two 
recursive specifications, it suffices to argue that Pi C Pj in 

Pi =ti(P),...,P„ =t„(P) 

is decidable. This follows from the assertion 

Vi, J < n 7r„(P,) C ^„(P,) P, C Pj, (1) 

where 7r/(Pfc) is defined by TTi{tk{P)), because C is decidable for finite threads. 
Without loss of generality, assume n > 1. To prove (jT]), observe that <^ follows 
by definition of regular threads. For the reverse, choose i,j and assume that 
T^niPi) ^ T^niPj)- Supposc Pi ^ Pj , then for some k > n, TTkiPi) % n^iPj) while 
T^k-i{Pi) ^ T^k~i{Pj)- So there exists a trace of length k from P,; of the form 



that is not a trace of Pj, while by the assumption the first n actions are a 
trace of Pj. These n actions are connected by n + 1 states, and since there are 
only n different states Pi, ...,P„, a repetition occurs in this sequence of states. 
So the trace witnessing nk{Pi) % T^kiPj) can be made shorter, contradicting 
A:'s minimality and hence the supposition. Thus Pi C Pj. Consequently, also 
P = Q (i.e., P E Q and Q C P) is decidable for regular threads P and Q. 
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2.2 Services 



A service is a pair (E, F) consisting of a set S of so-called co-actions and a rep^j/ 
function F. This reply function is a mapping that gives for each finite sequence 
of co-actions from S a reply value true or false. Services were introduced in [11] 
under the name "state machines" . 

Example 2 A down counter or loop counter is a service DC = {^,F) with 
E = {dec, set:n \ n € 1} consisting of the decrease and set co-actions for some 
/ C N and the reply function F which replies true to set:n while setting DC to 
value n, and true to dec if DCs value is positive while decreasing its current 
value, and false to dec if and only if the counter is zero. The initial value of DC 
is zero and usually I will be an initial segment ofN. 

Down counters (also known as timer units) are crucial components of most 
embedded systems and included in many microcontrollers (see e.g. [2]). Below, 
we return to this example. 

In order to provide a specific description of the interaction between a thread 
and a service, we will use for actions the general notation c.a where c is the 
so-called channel or focus, and a is the co-action. For example, cine is the 
action which increases a counter via channel c. This interaction is is defined 
with help of the use operator / . For a service S = (S, F), a finite thread P and 
a channel c, the defining rules for P/^ S (the thread P using the service S via 
channel c) are: 

S/c S ^5, 
D/c 5 = D, 

(P < c'.a > Q)/c S = {P/c S) < c'.a > {Q/,. S) if c' ^ c, 
(P < c.a >Q)lcS = P/c 5' if a e S and F{a) = true, 
(P < c.a > Q)/c 5 = Q/c 5' if a G E and F(a) = false, 
[P <c.a\>Q)/cS = D li a ^ S. 

where S' = (E, F') with F'{a) = F{aa) for all co-action sequences a G E+. The 
use operator is expanded to infinite threads P by defining 

P/,5= □ 7r„(P)/e5. 

(Cf. [1].) As a consequence, P/c 5 = D if for any n, 7r„ (P)/c 5 = D. Of course, 
repeated applications of the use operator bind to the left, thus 

P/cO So/cl Si = (P/cO So)/cl Si. 

We end this section with an example on the use of a service, showing that 
non-regular threads can be specified with infinite state services. 
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Example 3 We may extend the down counter defined in Example \^to a full 
counter C by including co-actions inc (increase) which always yield reply true 
while increasing the counter value. Now let {a, 6, cine, c. dec} C A. We write 
C{n) for a counter with value n €N, so C — C(0). By the defining equations for 
the use operator it follows that for any thread P , 

(c.incoP)/,C(0) = P/cC(l), 

and V?i G N, {cine o P)/c C(rt) = P/c C{n + 1). Furthermore, it easily follows 
that 

(P < c.dec > S)/c C{n) = J ^ " = 0, 

I P/c C(n — 1) otherwise. 

Now consider the regular thread Q defined 6?0 

Q = (cine o 0) < a > P, 
R = 6o P< c.dec >S. 

Then 

Q/^ C(0) = ((cine o Q) < a > P)/c C(0) 
- (g/cC(l))<a>(P/eC(0), 

and for all n e N, Q /c C{n) = (Q/c C(n + 1)) < a > (P/c C(n). It is not hard 
to see that Q /c C(0) is an infinite thread with the property that for all n, a 
trace of n + 1 a-actions produced by n positive and one negative reply on a is 
followed by b" o S. This yields an irregular thread: ifQ/cC{0) were regular, it 
would he a fixed point of some finite linear recursive specification, say with k 
equations. But specifying a trace b^ o S already requires k + 1 linear equations 
Xi — bo X2, Xk — bo Xk+i, Xk+i ~ S, which contradicts the assumption. So 
Q/c C(0) is not regular. 



3 Programs and Program Algebra 

In this section we introduce the program algebra PGA (see [5]) and discuss its 
relation with thread algebra. Furthermore, we shortly discuss the unit instruc- 
tion operator. 



3.1 PGA, basics of program algebra 

Given a thread algebra with actions in A, we now consider the actions as so- 
called basic instructions. The syntax of PGA has the following primitive in- 
structions as constants: 

^Note that a linear recursive specification of Q requires (at least) five equations. 
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Basic instruction a € A. It is assumed that upon the execution of a basic in- 
struction, the (executing) environment provides an answer true or false. 
However, in the case of a basic instruction, this answer is not used for 
program control. After execution of a basic instruction, the next instruc- 
tion (if any) will be executed; if there is no next instruction, inaction will 
occur. 

Positive/negative test instruction ±a for a G A. A positive test instruction +a 
executes like the basic instruction a. Upon false, the program skips its 
next instruction and continues with the instruction thereafter; upon true 
the program executes its next instruction. For a negative test instruction 
—a, this is reversed: upon true, the program skips its next instruction and 
continues with the instruction thereafter; upon false the program executes 
its next instruction. If there is no subsequent instruction to be executed, 
inaction occurs. 

Termination instruction !. This instruction prescribes successful termination. 

Jump instruction [k G N). This instruction prescribes execution of the 
program to jump k instructions forward; if there is no such instruction, 
inaction occurs. In the special case that A: = 0, this prescribes a jump to 
the instruction itself and inaction occurs, in the case that fc = 1 this jump 
acts as a skip and the next instruction is executed. In the case that the 
prescribed instruction is not available, inaction occurs. 

PGA-terms are composed by means of concatenation, notation _; _, and rep- 
etition, notation (_)'^. Instruction sequence congruence for PGA-terms is ax- 
iomatized by the axioms PGAl-4 in Table [TJ Here PGA2 is an axiom-sc/ieme: 
for each n > 0, (X")'^ = X", where ^ X and X^+^ = X;X^. A closed 
PGA-term is often called a PGA-program. 



Table 1: Axioms for PGA's instruction sequence congruence 



{X;Y)-Z 


= X;{Y-Z) 


(PGAl) 




^ X"^ for n > 


(PGA2) 


X'^-Y 


= X"^ 


(PGA3) 


{x-yy 


= X-{Y-Xr 


(PGA4) 



From the axioms PGAl-4 one easily derives unfolding, i.e., 

X"^ = X;X'^. 

Furthermore, each PGA-program can be rewritten into an instruction equivalent 
canonical form, i.e., a closed term of the form X or X; with X and Y not 
containing repetition. This also follows from the axioms in Table [T] 



9 



We will often use basic instructions in so-called focus. method notation, i.e., 
basic instructions of the form 

f.m 

where / is a focus (channel name) and m a method name. The m here is 
sometimes called a service-instruction because it refers to the use of some ser- 
vice, and is related with a co-action as defined in Section 12.21 Two examples 
of instructions in focus. method notation are cine and c.dec, related with the 
actions controlling a counter discussed in Example [31 In the next section we 
will relate all basic and test instructions to the actions of a thread; this is called 
thread extraction. 

3.2 Thread extraction: from PGA to thread algebra 

The thread extraction operator \X\ assigns a thread to program object X. 
Thread extraction is defined by the thirteen equations in Tabled where a ^ A 
and w is a primitive instruction. 



Table 2: Equations for thread extraction on PGA 



|!| 


= S 


\a\ 


— aoD 


l+a| 


= a D 




= a D 




= S 


\a;X\ 


= ao\X\ 


\+a;X\ 


= |X|<a>|#2;X| 


\-a;X\ 


= m;X\<a^\X\ 


\#k\ 


= D 


l#0;X| 


= D 


l#i;^l 


= 1^1 


|#fc + 2;u| 


= D 


|#fc + 2;u;X| 


= l#fc + i;^l 



Some examples: 

|(#0r| = |#0;(#Or| = D, 

\-a;b;c\ = |#2; 5; c| < a > |6; c| 
= |#l;c| < a > 5o |c| 
= \c\<a\>bocoD 
= coD<a>feocoD. 
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In some cases, these equations can be applied from left to right without ever 
generating any behavior, e.g., 

|(#2; ar\ - |#2; a; (#2; = |#1; (#2; ar\ = |(#2; = 

In such cases, the extracted thread is defined as D. 

It is also possible that thread extraction yields an infinite recursion, e.g., 

la'^l = \a\d^\ =ao la'^l 

(in the previous section we denoted this thread by a°°). If the behavior of X is 
infinite, it is regular and can be represented by a (linear) recursive specification, 
e-g-, 

|(a; +6; #3; -h- #4)^| ^ P in P = a o {P <b>Q), 

Q ^ P<b>Q. 

It follows easily that any PGA-program defines a regular thread, and conversely, 
each regular thread can be defined in PGA: linear equations of the form X = S 
OT X — D can be defined by instructions ! and ^0, respectively, and a linear 
equation 

X = Y ^al>Z 

can be associated with a triple +a; ^fc; Connecting these program fragments 
in a repetition and instantiating the jump counters k and / with the appropriate 
values then yields a PGA-program that defines a solution for the first equation. 
A typical example: 

Pi^P2<a\>P2, (+a;#2;#l; 
P2 = F3<6>Pi, ^ +&;#2;#2; 

Pg = D. #0)-. 

For PGA-programs X and Y we write 

X=beY 

if A" and Y are behaviorally equivalent (i.e., have the same behavior). Behavior 
equivalence is not a congruence, e.g., #0 =be #1 but #0;a Finally, 
for a PGA-program X we define 

X/cS 

as the program with behavior \X\/c S, thus \X/c S\ = \X\/c S. 
3.3 PGAu, PGA with unit instruction 

In [6] the unit instruction operator, notation u(_) is introduced. This operator 
wraps a program fragment into a single unit: if X is a program, then u(A') is a 
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unit that upon execution behaves as X, but that counts as a single instruction 
in any context. A typical example is 

+a;u(fe'^);c 

which behaves as 

\b'^\<al>\c\. 

A PGA-program that defines the same thread as the above example is for in- 
stance 

+a; (#2;#3;6;#3;c; #0)". 

Typically, a jump to a non-starting position in a unit is not possible, while a 
jump out of a unit can occur in any position of its body. As an example, 

+a; #3; u(-|-6; #3;c);d;e 

defines the same thread as +a; ^5; +b: c; d; e, i.e., 

|e| <a> (|e| <b\> |c;d;e|). 

Incorporating the unit instruction operator in PGA, notation PGAu, does not 
increase the expressive power. In this paper we shall make a modest use of the 
unit instruction operator and we refrain from describing the projection semantics 
for PGAu as defined in [15]. 1 

The projection semantics for PGAu is defined by a projection function 
pgau2pga (in [15 ) on first canonical PGAu-forms, i.e., closed terms of the form 
X OY X\ with X and Y not containing repetition. In the particular case that 
a program contains no units, these are first canonical forms in PGA. Further- 
more, the projection pgau2pga yields in all cases PGA-programs of the form 
(ui; Ufc)" and has definitional status. Consequently, each PGAu-program — 
and therefore each PGA-program — can be expressed in this form. In the next 
section we will use this property for PGA extended with rigid loops. 

4 PGA with rigid loops 

In this section we add two types of non-primitive instructions to PGA, thus 
obtaining PGA with rigid loops. Then we discuss a projection semantics that 
maps programs to PGAu using counters. We postulate that this semantics has 
definitional status and argue that this is a reasonable proposal by discussing a 
"pure projection" . Finally, we consider some degenerate examples. 

■^This formal semantics is implemented in the PGA Toolset 1131 and — including an appli- 
cation of "jump-optimization" — yields for the examples above 

+a;{#2;#3;6;#5;c;#0)'^, and 

+a; (#5; +b; #3; c; d; e; #0)" respectively. 
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4.1 PGArl, PGA with rigid loops 



We add two types of non-primitive instructions to PGA, thus obtaining PGArl, 
i.e., PGA with rigid loops: 

Rigid loop header instruction nx{ for each 71 G N \ {0}. Examples are 7x{ and 
432x{. This instruction prescribes an n times repeated execution of the 
program fragment until the following complementary rigid loop closure 
instruction. During execution of the body, jumps out of it are permitted 
and will end its execution; termination within a loop entails termination 
of the whole program and so does a livelock (#0). A jump into the body 
of a rigid loop prescribes the execution of its remaining instructions. 

Rigid loop closure instruction }x. This instruction ends the body of a rigid 
loop. 

The idea is that the matching of header and closure instructions is innermost- 
outermost: instruction sequences are parsed left-to-right, so a closure instruction 
matches the last preceding rigid loop header. 

The semantics of PGArl is given by a projection which makes use of an 
intermediate stage involving annotated closure instructions for rigid loops and 
annotated jumps out of rigid loops. 

Annotated rigid loop closure instruction n}xm for each n and r7i G N. This in- 
struction ends the body of a rigid loop with counter value n -I- 1 of which 
the body has a size of m instructions. Its execution is best explained in 
the presence of a separate loop counter RLC (cf . Example [J) which is ini- 
tialised at n before execution of the rigid loop and records the number of 
repetitions still to be done. Executing the annotated closure instruction 
then consists of #1 if the loop counter RLC has reached value and oth- 
erwise a jump to the first instruction of the loop body. These activities 
must be packed into a single unit in order to preserve the validity of other 
jumps elsewhere in the program. 

In the case that there is no associated rigid loop header instruction, the 
annotation is 0}xO. 

Annotated jump instruction ^I{ji,ni){j2,n2)...{jk,nk) with ji,ni,k £ N for a 
jump =^l that jumps over k annotated closure instructions nijxmi,..., 
rifcjxmfc at positions The annotation will be used to reset all 

concerning loop counters. 

As an example, 3x{; a; b; 4x{; H-c; #4; }x; d; }x; +e] #3 yields the annotation 
3x{; a; b; 4x{; +c; #4(7, 3)(9, 2); 3}x2; d; 2}x7; +e; #3. 
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We start with the case that a PGArl-program is of the form 

a form which easily facihtates a backward jump to the first instruction of the 
body of a rigid loop. We adopt the following restrictions on (ui; Ufe)'^: 

• each rigid loop header instruction has a complementary closure instruc- 
tion, 

• for each jump instruction #m it holds that m < fc (if not, subtract k 
sufficiently often), 

• rigid loop closures are not preceded by a test instruction. 

For the projection we need first to add the annotations, and then to introduce a 
service for a loop counter attached to each annotated rigid loop closure instruc- 
tion. The closure instruction at position i will make use of service rlc:i. A loop 
counter has methods set:n which initialises it to n and dec which subtracts 1 
if possible while returning a reply true and otherwise returns the reply false. 

The projected program begins with an initialisation instruction rlc:z.set:ci 
where Cj is the left annotation of the annotated loop closure instruction for 
each rigid loop that occurs in the candidate program. The loop headers are 
projected to #1 and their only role has been to determine the annotations for 
the closure instructions. Thus, assuming that Ui;...;Uk contains I rigid loops 
with annotated closure instructions at positions ii, 12, ii, we define 

pgarl2pgau((ui; Uk)'^) = rlc:ii.set:Cii; rlc:i2.set:Ci2; rlc:i;.set:cj;; 

(■^i(Mi); ...■,ll)k{Uk))"/rlc:ii RLCi^ /ric: RLCj^ .../ric:j, RLCj, 

with 

V'i(nx{) = #1, 
■^i{#l{ji,ni)...{jm,nm)) = u(rlc:ji.set.ni; 

rlc:j„.set.n„j; #1), 
'ipi{n}xm) = u( -|-rlc:«.dec; #3; 

rlc:z.set:n; #2; 

#fc - m), 
^i{u) = u otherwise. 

Note that in case (wi; does not contain rigid loop instructions, we have 

by definition that pgarl2pgau((ui; Ufc)'^) = {ui; Uk)" ■ 

As a first example, (3x{; a; b; 4x{; c; }x; d; }x; e)"^ yields the annotated pro- 
gram 

(3x{; a; b; 4x{; c; 3}xl; d; 2}x6; e)'^. 
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which yields under pgarl2pgau 

rlc:6.set:2; rlc:8.set:3; 

(#1; a; 6; #1; c; u( +rlc:6.dec; #3; 

rlc:6.set:2;#2; 
#8); 

d; u(+rlc:8.dec;#3; 
rlc:8.set:3;#2; 

#3); 

f')""/rlc:6 RLCe/rlcrS RLCg 

and thus defines the thread P given by P = (a o o o d)^ o e o P. 

As a second example, consider the program (a; 2x{; +&; #3; }x; c; d)", thus 

(a;2x{;+6;#3(5,l);l}x2;c;dr, 

wliich has the option of ending a rigid loop by jumping out of it: under 
pgarl2pgau we obtain 

rlc:5.set:l; 

(a;#l;+6; u(rlc:5.set:l; #3); 

u( +rlc:5.dec; #3; 
rlc:5.set:l;#2; 

#5); 

C; d)"/rlc:5 RLC5 

which defines the thread P given by 

P = ao{doP<h>{doP<b>codoP)). 

For a repetition-free PGArl-program m; ...^Uk we define 

pgarl2pgau(ui; ...;ufe) = pgarl2pgau($(ui; ...;ufe)), 
where the transformation $ is given by 

$(wi;...;ufc) = ((/)i(ui);...;</>feK);#0;#0)'^, 

4'i{#n) = #min(n, fc-l-2-i), 
<j)i(u) = u otherwise. 

Here the latter two #0-instructions serve the case that Uk is a test instruction. 
It remains to define the projection pgarl2pgau for first canonical forms 

ui; ...;ufe; {vf, ...■,viY 
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with k,l > 0. In this case wc may assume that if Ui = =ffm, then m < k — i + I 
(otherwise, subtract I sufficiently often). Similarly, we may assume that if Vj = 
#m, then m < I. We define 

pgarl2pgau(ui; Uk; (f i; VmT) = pgarl2pgau(S(ui; Uk; (wi; VmT)) 
with 

E{ui] Uk, {vi; = (ui; Uk; ^m(Wm); 
= #n + fc + 2 if i + n > m, 
^j(w) = u otherwise. 

This completes the definition of pgarl2pgau and we give this projection def- 
initional status. In other words, the loop counter service based projection 
pgarl2pgau is the defining projection for PGArl. 

4.2 Pure projection of rigid loops and definitional status 

In the previous section we assumed that PGArl-programs satisfy a certain well- 
formedness criterion: 

• each rigid loop header instruction has a complementary closure instruc- 
tion, 

• for each jump instruction #rn in (ui; Uk)'^ it holds that m < fc (if not, 
subtract k sufficiently often), 

• rigid loop closures are not preceded by a test instruction. 

Before dealing with programs that are not well-formed, we first discuss pure 
projection of well-formed PGArl-programs. 

The pure PGA projection pgarl2pga expands the body of each loop while 
adapting appropriately the jumps that go into the body and that might exit 
from the body. Expansion can be defined in a left-to-right order on rigid loop 
headers in the following way: let X be a (possibly empty) sequence of PGA- 
instructions, Ui range over the PGArl-instructions, and let Y range over finite 
(possibly empty) sequences of PGArl-instructions. Then 



and for all n > 1, 

X; (n + l)x{; m; Uk; }x; Y = X'; #1; u[; u'^; #1; nx{; m; Uk; }x; Y (3) 



X' = X, except that all jumps in X that pass (n + l)x{; Ui; Uk', }x 



X; lx{; ui; Uk; }x; Y = X; #1; ur, Uk; #1; Y 



(2) 



where 




#m + k + 2 if Uj = #m and i + m > k + 1 
Ui otherwise. 



are raised with k + 2. 
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With these two equations all rigid loops can be removed in (wi; m^)'^, and 
defining 

pgarl2pga(X) ^ X if X is a PGA-program 
completes the definition of this pure projection. 

We first argue that the expansion equation ([3]) is sound for the finite case. 

Let 

<i = vi; Vr; {n + l)x{; ui; ut; }x; wi; Ws, 

<2 = v[; ..r,vl\#l-,u[; ...;u'f.;#l;nx{;ui; ...■,Uk;}x;wi; ...;ws. 

We show that pgarl2pgau(ti) =be Pga-rl2pgau(i2 ) by case distinction on the 
various instructions in ti, assuming ti contains I rigid loops with their closure 
instructions at positions ii, ...,ii (so ii = r + k + 2). Without loss of gener- 
alization we further assume that jumps outside the program are such that in 
ti; #0; #0 they end in one of the latter two #0 instructions, and thus we can 
and will leave out the repetition in pgarl2pgau(ii). By a similar argument, the 
repetition in pgarl2pgau(f2) is left out. 

With respect to the instructions w;, the only interesting case is Vi — #j with 
i + j > r. We distinguish four sub-cases: 

a. lii+j = r + l, this prescribes a jump (via ^1) to the instruction "0^+2(^1). 
In t2's projection there is a jump to the instruction 'ijjr+2{u'i) . We proceed 
with this case below. 

b. Ifr-fl < i+j < r + k + 2, then 'ipq{up) in ti's projection and the associated 
ipq{Up) in t2's projection have to be related. We proceed with this case 
below. 

c. lii+j = r + k + 2, then pgarl2pgau(ii) is further determined by 

#l;ipr+2{ui); ...;V'r+fc+i(ufe);u(...); 

V'r+fe+3(wi); ...;Tpr+k+s+2iWs); #0; #0/rlc:r+/c+2 RLCr+fe+2(n - 1)... 

and so is pgarl2pgau(i2) (although all its ^/'-indices and foci- and counter- 
indices are raised with k + 2, but this is not significant). So in this case, 
pgarl2pgau(ti) pgarl2pgau(t2). 

d. If i + j > r + k + 2, then in both pgarl2pgau(ti) and pgarl2pgau(i2) 
this prescribes a jump to the w-part or to one of the two added #0's and 
RLCr+fe+2 respectively RLC,.+2/£+4 do not play a role, so also in this case 
behavioral equivalence holds. 
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According to the first two cases it remains to be proved that 

iir+t+i{ut)] V'r+fc+i ("fe); 

Ipr+k+siwi); ■0r+fe+s+2(u's); #0; #0/ric:r+fc+2 RLC.r+A;+2 (n) . . . 
= be (4) 

'tpr+z+i{u'i);...;ipr+k+i{u'k);#l;#l;A+k+4(ui); ...;V'r+2fe+3(ufc);u(...); 

V'r+2fc+5(«^l); iJr+2k+s+4{Ws)] #0; #0/rlc:r+2fe+4 RLCr+2fe+4(»^ - l)--- 

for i = 1, /c. We discuss the fohowing cases: 

e. If Ui = =ffj and i + j = fc + 1, then in the Ihs above the rigid loop is 
restarted at its first instruction with counter value n — 1, and so happens 
in the rhs, so the behavioral equivalence in ^ holds. 

f. If Ui — and i + j > k + 1, this prescribes in both sides a jump to the 
w-part or to one of the added #0's, and the behavioral equivalence in Q 
holds. 

g. If Ui = mx{ (and its closure instruction is in the M-part), then in both the 
Ihs and the rhs that rigid loop is either completed and behavior proceeds 
while the index i in ([?]) has raised, or the loop is jumped out and the 
resulting position either matches one of the two cases above, or is into the 
M-part. In the latter case, also the index i in (|4|) has raised. 

It follows that for all instantiations of Ui we either obtain the behavioral equiv- 
alence in (jH) , or the index i raises until we are at least at position r + fc + 2 and 
behavioral equivalence then follows from the sub-cases (jg) and ([d| above. This 
completes our argument on the soundness of equation ^ for the finite case. A 
comparable, but more simple analysis reveals the soundness of equation ([2|) for 
finite PGArl-programs. 

The iterative case is slightly more complex, as jumps can have a backward 
target. However, a similar analysis shows that also in this case both equations 
^ en ([3]) are sound. This completes our argument on the soundness of the pure 
projection pgarl2pga. 

The pure projection clearly provides a combinatorial explosion. It can be 
concluded that the loop counter service based projection pgarl2pgau is indeed 
the best candidate for a defining semantics: it satisfies both the criterion norma- 
tive semantic adequacy and the criterion indicative algorithmic adequacy while 
the pure projection satisfies only the first one. 

The projection pgarl2pgau defines the meaning of rigid loop instructions 
also for the degenerate case that a rigid loop header instruction has no associated 
closure instruction or vice versa: such a lonely instruction acts as a skip (i.e., 
4/^1). Finally, note that a rigid loop body of length is unproblematic: it has 
no behavioral impact (of course, this holds as well for the pure projection). 
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5 Conclusions 



First we note that the defining projection pgarl2pgau uses finite state services. 
Indeed, any PGArl-program not containing repetition can be expanded to one 
without rigid loops (using the expansion equations ^ and (O). 

Although rigid loops are less expressive than arbitrary loops and fail to 
express all finite state threads they can be proven sufficient for programming 
state transformations on finite Maurer computers (see [Slinilinj)- Admittedly 
one may be forced into using quite large loop counters but in principle it works. 



Acknowledgement. We thank Bob Diertens for valuable remarks. 
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